Technical Field
The present disclosure relates generally to computer aided design (CAD), and more specifically to techniques for converting CAD descriptions among data formats.
Background Information
Computer aided design (CAD) applications typically maintain CAD descriptions of physical structures (e.g., buildings, civil infrastructure projects, etc.) using data item arranged according to a storage format. One type of storage format (referred to herein as a “file-based storage format”) involves one or more files (e.g., a root file and one or more attached files) that maintain a series of data structures that represent elements organized into models, associated with levels that help define graphical views. In such a storage format, elements generally describe individual units of the structure. For example, in a simple CAD description of a building, elements may represent walls, doors, windows, furniture, etc. Models generally group together related elements into larger units, effectively “owning” a set of elements. A CAD description consists of at least one model (e.g., a root model), and often a number of additional models (e.g., attached models) organized under the root model using attachments to form a model graph. For example, in a simple CAD description of a building, a root model may represent an overall building, and may reference, via attachments, attached models that represent individual floors, each attached model owning elements representing walls, doors, windows, furniture, etc. disposed on a respective floor. A level generally describes selected elements that should be displayed (e.g., “turned on”) and, in some cases, symbology (e.g., color, line weight, line style etc.) that controls their visual appearance. For example, in a simple CAD description of a building, a level may include all the elements that represent windows, and indicate that such elements should be displayed with black, thin, dashed lines. Graphical views generally are representations of selected elements shown with certain symbology. For example, in a simple example CAD description of a building, a particular graphical view may show elements that represent walls and windows, with walls represented with black, bold, solid lines and windows represented in black, thin, dashed lines. Graphical views may be defined by attachment paths from a root model in the model graph, with the symbology and range of elements indicated by elements of the model graph, the levels to which the elements belong, and by attachment specific copies of levels (“attached levels”) that override the display status and symbology of the levels. Such an arrangement may be better understood by reference to the example in FIG. 1
FIG. 1 is a data structure diagram 100 of a portion of an example first storage format (e.g., a file-based storage format) for a CAD description. The data structure diagram 100 may be consistent with the DgnV8 format, compatible with CAD applications available from Bentley Systems, Inc. of Exton, Pa. However, it should be understood that similar formats may be used in other CAD applications, available from other vendors. The data structure diagram 100 represents a number of data items, embodied using various data structures. In the data structure diagram 100, a file data structure 110 serves as a header of each file (e.g., a root file or attached file), and includes a name field that indicates a unique human readable name for the file, a models field that references model data structures contained in the file, and a levels field that references level data structures contained in the file. Each model data structure 120 represents an individual model (e.g., a root model or an attached model) and includes a model ID field that indicates a unique identifier for the model, a name field that indicates a unique human readable name for the model, a file field that references the owning file, and elements fields that reference element data structures owned by the model. Each model may be located in a spatial coordinate system used to define the arrangement of its elements. Each element data structure 130 represents an individual element owned by a model and includes an element ID field that indicates a unique identifier for the element within the file, a model ID field that indicates the owning model data structure, a level field that indicates a level associated with the element, a data field that includes information describing the unit of the physical structure being represented by the element, and a DHDR field that indicates an associated DHDR data structure. Each DHDR data structure 140 indicates range and symbology information that describes how the owning element should be rendered, including a color field, a weight field and a style field. Each element data structure may reference a level data structure 150 for a level to which it belongs. Each level data structure 150 represents a level to which elements may belong, including a level ID field that indicates a unique identifier for the level, a name field that indicates a unique human-readable name for the level, a display field that indicates whether elements on the level should be displayed (e.g., “turned on”), and symbology fields, such as a color field, a weight field and a style field, that indicate overrides to the symbology of individual elements of the level.
A model graph is defined using attachment data structures that defines the ownership structure of models and the presence of any attached levels. Each attachment data structure 160 includes a file name field that references the file containing the attached model, a model name field that references the attached model, a transform field that indicates any spatial transform that may be applied to relate a spatial coordinate systems used by the attached model to that of the owning model, and attached level fields that references attached levels that may be used with the attachment. Each attached level data structure 170 defines overrides for an underlying level, and includes a level ID field that identifies the attached level, a display field that indicates whether the level should be displayed, and symbology fields, such as a color field, a weight field and a style field, that may override the symbology of the level. A graphical view may be defined in the model graph by a view data structure 190 that references a particular model data structure 120 that serves as a root for attachment paths of the model graph of the view. A variety of other data structures and fields may also be included in the first storage format.
It may be desirable to convert data items of a CAD description of a first storage format (e.g., a file-based storage format), such as the format depicted in FIG. 1, to a second storage format. The data items of the first storage format may be stored in a first repository (referred to in the context of a conversion as a “source repository”) and the data items of the second storage format may be stored in a second repository (referred to in the context of a conversion as an “output repository”). In some cases, repeated (e.g., periodic) conversions of data items between the first storage format of the source repository and the second storage format of the output repository may be necessary to maintain consistency, for example, where the CAD description in the source repository is periodically edited. In these cases, only a small portion of the data items in the source repository may have changed between consecutive conversions, and thereby performing a full conversion of all data items in the source repository may be highly inefficient. However, various technical challenges have hindered the development of effective incremental CAD description converters that are capable of detecting and processing only the data items that have changed.
Generally, little data items information is maintained indicating the provenance of each data item in the output repository. Determining which data item, or potentially data items, in the source repository yielded a data item in the output repository can be a complicated matter. There may not always be a 1:1 correspondence between in the source repository and data items in the output repository. Even if there is a 1:1 correspondence, the same globally unique identifier (ID) may not be utilized in both storage formats. Further, IDs may not be stable over time. For example, a source repository may reuse a same ID with a different data item at different times. All these issues hinder the use of conventional synchronization frameworks in implementing an incremental CAD description converter. Such frameworks generally place demands on the source repository and/or the output repository that cannot readily be met (for example, that the output repository keep a record of the provenance of every item in the output repository, or that the source repository itself provides an indication of every data item that has changed since a last conversion).
Accordingly, there is a need for improved techniques that may enable effective incremental CAD description conversion between data items of a source repository that uses a first storage format and data items of an output repository that uses a second storage format.